1. Field of the Invention
The present, invention relates generally to transaction processing, and more particularly to a transaction processing system in which transactions may reference old copies of the state memory of the system. Specifically, the present invention concerns a method of ensuring proper recovery in such a system when the results of each transaction are committed to an after-image log rather than being written into non-volatile state memory after each transaction.
2. Description of the Background Art
A desirable feature of a computing system is the ability to recover from partial system failures that may interrupt memory write operations. If an application program has a memory write operation in progress at the time of the system failure, it is possible that a memory record will become erroneous. To enable the recovery of memory records after a partial system failure, it is necessary for the application program to keep backup copies of the records in nonvolatile memory. When the computing system is restarted, the memory records to be recovered are replaced with the backup copies.
To facilitate the making of backup copies and the recovery of memory records, the operating system typically provides an established set of memory management procedures that can be invoked or called from an application program to define a "recovery unit." The recovery unit consists of program statements between a "START" statement and a "COMMIT" statement. All of the statements in the "recovery unit" must be completed before the memory records modified by the statements in the recovery unit are made available for subsequent processing. The statements in the "recovery unit" specify operations in a single "transaction." Upon recovering from a partial system failure, inspection of the nonvolatile memory will reveal that the operations in the single "transaction" are either all completed, or none of them are completed.
The operations in a single transaction may modify a number of files, and the files may be shared by other processes. During the transaction, the files may be inconsistent for a time, although the files will be consistent upon completion of the transaction. A typical example is a transfer of funds from one account to another, in which a first account is debited, and at a slightly later time, another account is credited. During the interim, the two accounts are inconsistent because the sum of the two accounts does not represent the total funds in the two accounts. Due to inconsistency when files are being modified by a transaction, it is known to prevent other processes from accessing the files until the modification is finished.
Transactions are typically distributed in transaction processing systems in such a way that the performance of a second transaction is begun before the results of a first transaction are committed. To ensure ease of recovery, the second transaction is usually precluded from reading any results of the first transaction before the first transaction commits. In a data base system, for example, a transaction places "write locks" on any data base records that are modified by the transaction. To ensure consistency of data read by a transaction, the transaction may also place "read locks" on any data base records that are read by the transaction.
The use of memory locks inhibits concurrency between transactions, which causes a decrease in transaction processing speed. In some systems, such as "Rdb/VMS" and "VAX DBMS" sold by Digital Equipment Corporation, a "snapshot" mechanism eliminates the need for read locks and also prevents blocking of read operations by write locks. The "snapshot" mechanism permits a transaction to obtain, at any time, a consistent version of data existing at the time that the transaction begins.
In the "Rdb/VMS" and "VAX DBMS" systems sold by Digital Equipment Corporation, recoverability is ensured by flushing to an "undo log" the "before-images" of records to be updated, and then flushing the updated data records to state memory just before a transaction is committed. If a crash occurs, the updated records are replaced with "before images" that are obtained from the "undo log" to "undo" the effects of the transaction.
The "Rdb/VMS" and "VAX DBMS" systems have an optional feature called "After Image Journaling" that provides a facility to "roll forward" updates on a database restored from a backup copy. The journaling mechanism saves copies of records after they have been modified, along with other information permitting reconstruction of the changes made to the database.
The "undo" recovery mechanism of "Rdb/VMS" and "VAX DBMS" provides very fast recovery because only the effects of failed transactions must be undone. A considerable amount of processing time, however, is spent flushing updated records to state memory when each transaction is committed. In a stable environment where systems crashes are very infrequent, fast recovery is not particularly important. For transactions that update the same records for multiple transactions, and transactions that are short and do not update many pages, a considerable amount of processing time is wasted by flushing updated records to state memory at the end of every transaction.